Server side filtering and sorting with field level security

ABSTRACT

A project management system is enabled to implement filtering, sorting, and field level security for data associated with managed projects. A filter for field selection is prepared by a project client application and forwarded to a project server. The server generates an access attribute table based the user permissions that may be set for each field within the managed projects. Upon retrieving the selected fields from project database, the project server builds a secured list of fields. A data set to be provided to the project client is prepared by removing the fields for which the user lacks the requisite access permission prior to sorting the data. The removed data may be used for user-transparent computations within the project server, but guarded from client applications.

BACKGROUND

Project management systems include a number of applications, computingdevices, and input devices that schedule, track, and report tasks andresources associated with projects for a variety of organizations. Intoday's global economy, many enterprises execute projects in variouscountries, regions, and localities. While some projects may be managedat the local level and results reported to a higher organizational levelsuch as an enterprise level, other organizations might prefer toschedule and track projects across countries.

Project management systems typically have two prominent functions:calculation of project parameters, such as time and resource tracking,and presentation of calculation results to users in the form of reports.Additional functionalities such as workflow coordination, user alerting,performance evaluation, and the like may also be implemented as part ofthe project management system.

Because a variety of users may provide inputs and request reportsinvolving one or more projects within a project management system,security and user-friendly presentation of project data is a challengefor project management system designers and implementers.

SUMMARY

A project management system is directed at providing filtering, sorting,and field level security for data associated with managed projects. Afilter that is used for field selection may be based on one or morerules that may be prepared by a project client application and thenforwarded to a project server. The project server may generate a queryset based on the filter and an access attribute table based on userpermission rules for each field within the managed projects.

Upon retrieving the selected fields from a project database, the projectserver may build a secured list of fields. A sorted data set is preparedby removing fields for which the user lacks requisite access permission,which may then be provided to the project client.

Removed data may be used for user-transparent computations within theproject server, but guarded from client applications. Selection orpermission rules may be modified dynamically, if the original data ismodified by a user with permission.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a computing device in which a project managementsystem with server-side filtering and sorting according to an exampleaspect may be executed;

FIG. 2 illustrates an example system, where aspects of a projectmanagement system may be implemented;

FIG. 3 is a functional block diagram illustrating interactions between aclient, a server, and project server databases in a project managementsystem implementing server-side filtering, sorting, and field levelsecurity;

FIG. 4 is a conceptual diagram illustrating an architecture of a projectmanagement system implementing server-side filtering, sorting, and fieldlevel security;

FIG. 5 illustrates generation of an example report table base onoriginal data and assigned access attributes;

FIG. 6 illustrates an example command structure for implementingserver-side filtering, sorting, and field level security in a projectmanagement application; and

FIG. 7 illustrates a logic flow diagram for a process of implementingserver-side filtering, sorting, and field level security in a projectmanagement system.

DETAILED DESCRIPTION

Embodiments of the present disclosure now will be described more fullyhereinafter with reference to the accompanying drawings, which form apart hereof, and which show, by way of illustration, specific exemplaryembodiments for practicing the invention. This disclosure may, however,be embodied in many different forms and should not be construed aslimited to the embodiments set forth herein; rather, these embodimentsare provided so that this disclosure will be thorough and complete, andwill fully convey the scope to those skilled in the art. Among otherthings, the present disclosure may be embodied as methods or devices.Accordingly, the present disclosure may take the form of an entirelyhardware embodiment, an entirely software embodiment or an embodimentcombining software and hardware aspects. The following detaileddescription is, therefore, not to be taken in a limiting sense.

Illustrative Operating Environment

Referring to FIG. 1, an exemplary system for implementing someembodiments includes a computing device, such as computing device 100.In a very basic configuration, computing device 100 typically includesat least one processing unit 102 and system memory 104. Depending on theexact configuration and type of computing device, system memory 104 maybe volatile (such as RAM), non-volatile (such as ROM, flash memory,etc.) or some combination of the two. System memory 104 typicallyincludes operating system 105 and one or more program modules 106working within operating system 105.

In addition to program modules 106, project management application 107may also be executed within operating system 105. Project managementapplication 107 may be arranged to schedule, track, and provide variousreports of tasks and resources associated with projects.

In one embodiment, project management application 107 may facilitateserver-side filtering, sorting, and field level security. To perform theactions described above, project management application 107 may includeand/or interact with other computing devices and applications andapplication interfaces (APIs) residing in other applications such asfilter builder API shown in FIG. 3.

Computing device 100 may have additional features or functionality. Forexample, computing device 100 may also include additional data storagedevices (removable and/or non-removable) such as, for example, magneticdisks, optical disks, or tape. Such additional storage is illustrated inFIG. 1 by removable storage 109 and non-removable storage 110. Computerstorage media may include volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information, such as computer readable instructions, data structures,program modules, or other data.

System memory 104, removable storage 109 and non-removable storage 110are all examples of computer storage media. Computer storage mediaincludes, but is not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed bycomputing device 100. Any such computer storage media may be part ofdevice 100.

Computing device 100 may also have input device(s) 112 such as retaildevices, keyboard, mouse, pen, voice input device, touch input device,etc. Output device(s) 114 such as a display, speakers, printer, etc. mayalso be included.

Computing device 100 also contains communication connections 116 thatallow the device to communicate with other computing devices 118, suchas over a network. Communication connections 116 are one example ofcommunication media. Communication media may typically be embodied bycomputer readable instructions, data structures, program modules, orother data in a modulated data signal, such as a carrier wave or othertransport mechanism, and includes any information delivery media. Theterm “modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia includes wired media such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media.

FIG. 2 illustrates example system 200, where aspects of a projectmanagement system may be implemented. System 200 may include one or morenetworks that comprise any topology of servers, clients, Internetservice providers, and communication media. The networks may also have astatic or dynamic topology.

A project management application, such as project management application107 of FIG. 1, may reside on server 202. In one embodiment, theapplication may be run across distributed servers, mainframe computers,and the like in an enterprise environment. Server 202 may include anumber of other applications such as accounting applications, databaseapplications, communication applications, and the like.

In another embodiment, server 202 may interact with project database 204that is arranged to store project related data. Project database 204 mayalso be accessed directly by other components of the project managementsystem such as client devices, other servers, and the like.

The project management application may interact with client devices,such as handheld computer 214, desktop computer 215, and laptop computer216, over network 210 to collect data associated with the project(s),provide reports, and perform other project related tasks. Client devicescommunicating with server 202 may include any type of computing device,not limited to the examples shown herein.

In another embodiment, one or more client devices, such as handheldcomputer 211, desktop computer 212, and laptop computer 213, may bemanaged by a separate server (e.g. server 206) interact with server 202through server 206 for enterprise level project activities.

Network 210 may be a secure network such an enterprise network, or anunsecure network such as a wireless open network. Network 210 providescommunication between the nodes described above. By way of example, andnot limitation, network 210 may include wired media such as a wirednetwork or direct-wired connection, and wireless media such as acoustic,RF, infrared and other wireless media.

The present invention is not limited to the above-described environment,however. Many other configurations of computing devices, communications,applications, and distribution systems may be employed to implement aproject management application implementing server-side filtering,sorting, and field level security.

Illustrative Embodiments for a Project Management ApplicationImplementing Server-Side Filtering, Sorting, and Field Level Security

Organizations that manage multiple projects with different resources,users, locations, and the like, may have a number of concerns regardingefficient management of their projects and security of their projectdata, such as costs, on-time performances, and the like. Commonly,project applications filter and sort at the client. This may result indegraded performance, because more than the needed data is typicallyretrieved from the server. In addition, retrieval of data without anyrestrictions presents a security challenge.

Embodiments of the present invention are directed to implementingserver-side filtering, sorting, and field level security. According toone embodiment, the server-side filtering, sorting, and field levelsecurity is implemented within a project management system. Manyprojects involve a number of users who are responsible for managingresources and tasks associated with the project. The users may receivereports from the project application, periodically or upon request. Suchreports may include status of tasks or resources, costs, performance,comparisons, and the like.

In some cases, users may be allowed to view reports for tasks andresources not necessarily managed by them. In other cases, an enterpriselevel project manager may desire to restrict permissions based onpredetermined criteria. In yet other cases, multiple projects may bemanaged at the enterprise level and different users may have differentpermissions based on their position within the enterprise. For example,marketing managers may be allowed to view progress reports for allprojects, while accounting managers may only be allowed to view costreports for certain projects. Thus, a complex system of accesspermissions may be desired by the enterprise for its projects.

FIG. 3 illustrates functional block diagram 300 of interactions betweena client, a server, and project server databases in a project managementsystem implementing server-side filtering, sorting, and field levelsecurity.

Use of assigned access attributes in determining which data to retrievefrom the project database greatly enhances security aspects of theproject management system. A middle layer is formed between the projectapplication and the project database. In some embodiments, informationabout the user requesting a report is gathered to determine whether theyhave been granted access to the data and at what level. Each user'spermissions may be determined by the permissions assigned to the user inan access rights table, one or more rules that combine access rightsemploying logic parameters, or by a system administrator.

When a filter/sort query is formed to retrieve data for a report, theassigned access attributes are first checked to determine if a portionof the data (e.g. specific fields in a project or data associated with awhole project in a multi-project system) is restricted. If the user doesnot have access to that portion of the data, it is not retrieved orincluded in the report. In another embodiment, the restricted data maybe retrieved for calculation purposes, but not presented to the userwithout permission.

Referring to FIG. 3, client logic 312 within client application 310 usesFilter Builder API 314 to build a filter that is then passed to server320 that implements a filtering API on the server middle tier.

In one embodiment, the filtering API is called Query Builder API (324).Query Builder 324 is responsible for building database queries thatreturn the data, wrapping security around the query, and ensuring thedata is not extracted through metadata. The filter and the query may beformed as eXtensible Mark-up Language (XML) documents.

Without an adequate security mechanism, data may be extracted throughmetadata by users without permissions. For example, in a project systemthat simply hides the restricted data, but does not remove it fromfiltering or sorting operations, a user may use multiple queries tofocus on the hidden data. A user may also use sorts on “invisible”fields providing related information to retrieve the hidden data.

Accordingly, Query Builder API 324 interacts with security block 326 inpreparing the query based on assigned access attributes. In someembodiments, the restricted data may be retrieved from project databases304, and only used for calculations that are transparent to the user.

Non-database filters 330 may be applied to the retrieved data after itpasses through security 328. Such filters may include filters based onresource availability within a specific time range (Availability 336),calculated proficiency (Proficiency 334), further sorting and grouping(Sort/Group 332), and the like. The filtering mechanism may be arrangedto handle “soft schema” supporting customer-defined fields.

The project management system may also be enabled to handle two basesecurity objects and to apply the rules consistently. The rules areapplied depending on which of the base security objects is being used asthe primary access path and which data is being retrieved. Projectmanagement system, typically, has two main objects: projects andresources, which overlap at the assignment level (where a resource isassigned to a task in a project). The data in the assignment may comefrom both the resource and the project.

Project Server Interface (PSI) 322 is responsible for ensuring that thefilter makes sense within the context of its domain (for example, aroutine that deals exclusively with resource data does not expectproject data in the filter). PSI 322 also invokes Query Builder API 324.

Applying the filtering and security mechanisms after all of the data isretrieved from project server databases 304 may be costly with regard toprocessing resources. This work may not be shared with clientapplication for security reasons. Hence, field access control inretrieving data is directed at providing the needed security.

FIG. 4 is a conceptual diagram illustrating an architecture of projectmanagement system 400 implementing server-side filtering, sorting, andfield level security.

In the example architecture, individual projects P1 and P2 are managedlocally at sites 416 and 418. Sites 416 and 418 may be client devices,client applications running on client devices, client applicationsrunning on a central server, and the like. In one embodiment, projectsP1 and P2 may be managed partially or completely by project server 420.In another embodiment, client devices 416 and 418 may provideinformation to project server 420 for project roll-ups and enterpriselevel management tasks, and request reports from project server 420.

Field access control may be applied to individual fields or to groups offields. For example, the individual fields may be types such as defaultfields, local custom fields, enterprise level custom fields, and thelike. The groups of fields may be groups such as costs, baselines, andthe like.

Sites 416 and 418 may provide their input data directly to projectdatabase 1 and project database 2 (442 and 444). Project server 420 isalso configured to retrieve and save project data to the databases 442and 444. In another embodiment, project server 420 may save securityinformation such as permission rules, assigned access attributes, andthe like, in security database 446.

In addition to performing actions associated with project calculations,project server 420 may publish project reports, such as summary taskcost calculations, schedules, cost accruals, and the like, to clientsand other users (e.g. enterprise servers) in reports 1, 2, 3 (452, 454,and 456).

The invention is not limited to the example components and operationsdescribed in conjunction with FIGS. 2, 3, and 4. Other components andoperations may be implemented using the principles described herein.

FIG. 5 illustrates generation of an example report table base onoriginal data and assigned access attributes.

As diagram 500 shows, a field access table containing assigned accessattributes may be generated from permission rule(s). Example table 510shows two fields (A and B) of two projects (P1 and P2). Accessattributes for a particular user are assigned based on a permission rulefor each field. In the example table, the user has no access permissionto field A of project P1, read/write access permission to field B ofproject P1 and field A of project P2, and read only access permission tofield B of project P2.

Example table 520 shows actual values of the selected fields within aproject database. The values may be cost, resource level, baseline,baseline cost, etc. As described previously, the fields may be selectedbased on criteria generated by a filter builder API in response toselection rules provided by a user.

Applying the security mechanism and the extensible filtering mechanism,a project server retrieves selected data and generates a primary tablesuch as table 530. Table 530 reflects actual values of the selectedfields for each project with the restricted values (fields with “deny”attribute, e.g. field A of project P1) having a “null” value.

The selected fields are then sorted according to predetermined criteria.During the sorting, “null” value fields are not included in the pool offields preventing a “process of elimination” type circumvention of thesecurity mechanism.

The invention is not limited to the attributes, field types, and tablesdiscussed above. Other attributes, field types, tables, and the like maybe implemented using the principles described herein.

FIG. 6 illustrates example command structure 600 for implementingserver-side filtering, sorting, and field level security in a projectmanagement application.

The example routine “FillTypedDataSet” may be called by a project serverinterface upon receiving a filter from a project client. First parameterwithin “FillTypedDataSet” is DataSet (602) defining the input data setagainst which the field list in the received filter is validated. If afield listed in the filter does not match the context of the filter'sdomain (e.g. a task field for a filter intended for a resource dataset), the filter is rejected. DataSet 602 is followed by the Filterparameter defining the received filter.

The parameters associated with the filter are followed by “Joins” (606),which is a list of joins between the tables in the data set. This isfollowed by the string variable “primaryCustomFieldTableName” (604)defining the primary custom field table for performing queries involvingcustom fields.

Next string variable “customFieldTables” (608) is a list of custom fieldtables that are to be handled differently. The guid, “resUid” (610), isthe resource for security that is used to restrict data access to thelist of projects/resources available to the caller. The guid, “permUid”(612), includes the permission list for security checks.

FIG. 7 illustrates a logic flow diagram for process 700 of implementingserver-side filtering, sorting, and field level security in a projectmanagement system.

According to one embodiment, a computer-implemented method for securelyfiltering data in a project management system includes preparing afilter based on a pre-defined selection criterion for project associateddata and retrieving the selected data from a project database. Arestriction status of the selected data is then determined based on anassigned access attribute, and the retrieved data is sorted based on theselection criterion and the restriction status. The sorted data isprovided to a client application, with a null value for restrictedportions of the data.

The filter may be validated for syntax and available data in thedatabase. The selection criterion and the assigned access attribute maybe derived from a rule. The retrieved data may be employed in auser-transparent project calculation regardless of the restrictionstatus. In one embodiment, the data is a field associated with a task ora resource of a project. The field may be a default field, a customfield, an extrinsic field, or an intrinsic field. The data may alsoinclude fields associated with a plurality of projects.

The assigned access attributes may be a read permission, aread-and-write permission, or a no-access permission. The assignedaccess attributes may be based on a default rule, a user-defined rule,or an extensible rule. The rules may be modified dynamically, if theoriginal data is modified by a user with permission.

Process 700 begins at operation 702, where a filter constructed by aroutine in a project client is received at the project server. Theclient may use Filter Builder classes to construct the filter from oneor more rules as described previously. Processing proceeds fromoperation 702 to operation 704.

At operation 704, the project server interface validates the filterverifying the filter matches the context of its domain, etc. Processingthen advances to operation 706.

At operation 706, and access attribute table is generated. The accessattribute table may be generated from a set of permission rules,retrieved from a security database, provided by a system administrator,and the like. Processing moves from operation 706 to operation 708.

At operation 708, the fields to be retrieved are determined. The fieldsto be retrieved are determined from selection criteria (or rules)provided by the filter. Processing moves next to operation 710.

At operation 710, the selected fields are retrieved from the projectdatabase. As mentioned previously, retrieval and processing of selectedfields only, as opposed to all of the fields, significantly increasesprocessing resource efficiency and reduces security risks. Processingadvances from operation 710 to operation 712.

At operation 712, a secured list of retrieved fields is built. Dataincluded in the secured list of fields is used to determine which fieldsare to be removed before sorting and presenting the sorted data to theuser. Processing moved from operation 712 to decision operation 714.

At decision operation 714, a determination is made whether the user hasrequired access permission(s). In a complex data set and projectmanagement system a set of data may be provided to multiple users withdifferent permissions for each field. In one embodiment, userpermissions may be conditional based on other variables such aslocation, time, stage of project, and the like. If the user haspermission for a field, processing advances to operation 716.

At operation 716, a data set is built by sorting the retrieved fieldswithout stripping any of the field values. Processing then moves to acalling process for further actions.

If the user does not have requisite permission for one or more of thefields, processing advances to operation 718 from decision operation714. At operation 718, the data set is built by sorting the retrievedfields and stripping any fields for which the user lacks accesspermission.

The restricted fields may still be used for user-transparentcalculations, but not included in the sorting process to prevent processof elimination type circumventions. After optional operation 718,processing moves to a calling process for further actions.

The operations included in process 700 are for illustration purposes.Using server-side filtering, sorting, and field level security in aproject management system may be implemented by a similar process withfewer or additional steps, as well as in different order of operations.

The above specification, examples and data provide a completedescription of the manufacture and use of the composition of theembodiments. Although the subject matter has been described in languagespecific to structural features and/or methodological acts, it is to beunderstood that the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims and embodiments.

1.-20. (canceled)
 21. A computer-implemented method for securelyfiltering data in a business logic application, comprising: receiving arequest for a portion of data associated with the business logicapplication, wherein the request includes a filter based on a rule forselecting the portion of data; preparing a query based on the filter andat least one security attribute associated with a user; retrieving theselected portion of the data; sorting the retrieved data based on thefilter and at least one post-processing criterion; and providing thedata to a requesting application.
 22. The computer-implemented method ofclaim 21, wherein the filter includes a look-up table based on the rulefor selecting the portion of data.
 23. The computer-implemented methodof claim 21, wherein preparing the query includes assigning the securityattribute to one of each field of the selected portion of data and agroup of fields of the selected portion of data.
 24. Thecomputer-implemented method of claim 21, wherein preparing the queryincludes assigning an enterprise level security attribute to one of eachfield of the selected portion of data and a group of fields of theselected portion of data.
 25. The computer-implemented method of claim21, further comprising determining the security attribute from one ormore rules.
 26. The computer-implemented method of claim 21, wherein theselected portion of the data includes at least one field associated withone of a cost and a baseline of a project.
 27. The computer-implementedmethod of claim 26, wherein the selected portion of the data includes afield for baseline cost that is derived from a comparison of thecorresponding cost and baseline fields.
 28. The computer-implementedmethod of claim 21, wherein preparing the query includes assigning asecurity attribute to a field of the selected portion of data byinferring the security attribute from at least one other field of theselected portion of data.
 29. The computer-implemented method of claim28, wherein the inferred security attribute is determined from a contentof the at least one other field.
 30. A project server for securelyfiltering and sorting project data, comprising: a communication moduleconfigured to communicate with a project client and a project database;a processor configured to: receive a request for a portion of theproject data from the project client, wherein the request includes aplurality of filters based on at least one rule for selecting theportion of the project data; determine at least one access attribute fora permission status of a user; prepare a query for a plurality ofprojects based on the plurality of filters and the permission status;retrieve a selected portion of the project data from a project databasebased on the query; sort the retrieved portion of the project data basedon a plurality of filters and access attributes for each project and atleast one post-processing criterion, wherein a predetermined value isused for restricted fields that are defined by the permission status;and provide the post-processed data to the requesting project client.31. The project server of claim 30, wherein the processor is furtherconfigured to prepare the query for the plurality of projects based ondistinct rules for each project provided by a plurality of projectclients.
 32. The project server of claim 30, wherein the processor isfurther configured to dynamically modify the query, if the selectedportion of the project data is modified.
 33. The project server of claim30, wherein the processor is further configured to determine the accessattributes at one of a field level, a group level, a project level, andan enterprise level.
 34. The project server of claim 30, wherein atleast one of the filters and the query are prepared in eXtensible MarkupLanguage (XML).
 35. The project server of claim 34, wherein the query isextensible.
 36. A business logic system for server-side filtering andsorting data in a secure manner, the system comprising: a databaseconfigured to store business logic data; a filter building moduleconfigured to: prepare a filter based on a selection criterion; a querybuilding module configured to: receive the filter from the filterbuilding module; determine access attributes based on a permission ruleassociated with a user; and prepare a query based on the filter and theaccess attributes for a portion of the business logic data; and aprocessing module configured to: retrieve a selected portion of businesslogic data from the database based on the query; determine a restrictionstatus of the retrieved portion of the data based on the accessattributes; sort the retrieved portion of the data based on the filter,wherein a null value is used for restricted data; and provide the sorteddata to a client application.
 37. The system of claim 36, wherein theprocessing module is further configured to post-process the restricted,sorted data with further selection criteria.
 38. The system of claim 36,wherein the filter includes at least one table derived from at least onerule associated with selecting the portion of the data.
 39. The systemof claim 36, wherein the processing module is further configured todynamically modify at least one of the filter and the access attributesin response to a change in the selected portion of the data.
 40. Thesystem of claim 36, wherein the processing module is further configuredto use the sorted data in a client-transparent operation regardless ofthe restriction status.